Assertion failure: false (MOZ_ASSERT_UNREACHABLE: Extra child frame found in nsVideoFrame. Possibly from stray whitespace around the videocontrols container element.), at nsVideoFrame.cpp:376, with contentEditable and "enableObjectResizing"
Categories
(Core :: Layout, defect, P5)
Tracking
()
People
(Reporter: tsmith, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: assertion, testcase)
Attachments
(1 file)
497 bytes,
text/html
|
Details |
Comment 1•6 years ago
|
||
Reporter | ||
Comment 2•6 years ago
|
||
This is hit frequently while fuzzing and impacts fuzzing performance. If this is not a valid or useful assertion can it potentially be downgraded to a warning?
Comment 3•6 years ago
|
||
I think so, but I'd pass the question to the author and reviewer of this code.
Updated•6 years ago
|
Comment 4•6 years ago
|
||
This can be addressed by inspecting the frame tree to find out what’s being generated, and accordingly, find the appropriate layout code to not to generate the child frame.
Comment 5•6 years ago
|
||
When we trip the MOZ_ASSERT_UNREACHABLE, the frame tree for the <video>
looks like this (and the unexpected child that triggers the assertion is the first Placeholder(span)
:
HTMLVideo(video)(4)@7ff0c119b3c8 parent=7ff0c119aae0 {14820,0,18000,9000} vis-overflow=-60,-60,18120,9120 scr-overflow=0,0,18000,9000 [state=004b404000001231] [content=7ff0bfcd3000] [cs=7ff0c11d8c48]<
ImageFrame(img)(-1)@7ff0c119b470 parent=7ff0c119b3c8 next=7ff0c119b568 {0,0,0,0} vis-overflow=0,0,1440,1440 [state=0009400000000208] [content=7ff0bfb76fc0] [cs=7ff0c11d8d38]
Block(div)(-1)@7ff0c119b568 parent=7ff0c119b3c8 next=7ff0c119b620 {0,0,18000,9000} [state=0009002800100208] [content=7ff0c03a5430] [cs=7ff0c11d84c8]<
>
HTMLScroll(div)(0)@7ff0c119b620 parent=7ff0c119b3c8 next=7ff0c1f6da28 {0,0,18000,9000} [state=008b020800000000] [content=7ff0c03649d0] [cs=7ff0c11d7898]<
Block(div)(0)@7ff0c119b860 parent=7ff0c119b620 {0,0,18000,9000} [state=020b000008d00220] [content=7ff0c03649d0] [cs=7ff0c11d85b8:-moz-scrolled-content]<
line 7ff0c119bac0: count=1 state=block,clean,prevmarginclean,not impacted,not wrapped,before:nobr,after:nobr[0x8] {0,0,18000,9000} <
Block(div)(3)@7ff0c119b918 parent=7ff0c119b860 {0,0,18000,9000} [state=000b022008100220] [content=7ff0c0364b80] [cs=7ff0c11d7c58]<
line 7ff0c119ba70: count=1 state=block,clean,prevmarginclean,not impacted,not wrapped,before:nobr,after:nobr[0x8] {0,0,18000,9000} <
FlexContainer(div)(1)@7ff0c119b9d0 parent=7ff0c119b918 {0,0,18000,9000} [state=0009022000900220] [content=7ff0c0364c10] [cs=7ff0c11d7d48]<>
>
>
>
>
>
Placeholder(span)(-1)@7ff0c1f6da28 parent=7ff0c119b3c8 next=7ff0c1f6d8f8 {0,0,0,0} [state=0001000000200402] [content=7ff0c11c7a60] [cs=7ff0c11fa2f8:-moz-oof-placeholder] outOfFlowFrame=Block(span)(-1)@7ff0c1f6d970
Placeholder(span)(-1)@7ff0c1f6d8f8 parent=7ff0c119b3c8 next=7ff0c1f6d7c8 {0,0,0,0} [state=0001000000200402] [content=7ff0c11c78b0] [cs=7ff0c11fa2f8:-moz-oof-placeholder] outOfFlowFrame=Block(span)(-1)@7ff0c1f6d840
Placeholder(span)(-1)@7ff0c1f6d7c8 parent=7ff0c119b3c8 next=7ff0c1f6d698 {0,0,0,0} [state=0001000000200402] [content=7ff0c11c7820] [cs=7ff0c11fa2f8:-moz-oof-placeholder] outOfFlowFrame=Block(span)(-1)@7ff0c1f6d710
Placeholder(span)(-1)@7ff0c1f6d698 parent=7ff0c119b3c8 next=7ff0c1f6d568 {0,0,0,0} [state=0001000000200402] [content=7ff0c11c7790] [cs=7ff0c11fa2f8:-moz-oof-placeholder] outOfFlowFrame=Block(span)(-1)@7ff0c1f6d5e0
Placeholder(span)(-1)@7ff0c1f6d568 parent=7ff0c119b3c8 next=7ff0c1f6d438 {0,0,0,0} [state=0001000000200402] [content=7ff0c11c7670] [cs=7ff0c11fa2f8:-moz-oof-placeholder] outOfFlowFrame=Block(span)(-1)@7ff0c1f6d4b0
Placeholder(span)(-1)@7ff0c1f6d438 parent=7ff0c119b3c8 next=7ff0c1f6d308 {0,0,0,0} [state=0001000000200402] [content=7ff0c11c74c0] [cs=7ff0c11fa2f8:-moz-oof-placeholder] outOfFlowFrame=Block(span)(-1)@7ff0c1f6d380
Placeholder(span)(-1)@7ff0c1f6d308 parent=7ff0c119b3c8 next=7ff0c1f6d1d8 {0,0,0,0} [state=0001000000200402] [content=7ff0c11c7040] [cs=7ff0c11fa2f8:-moz-oof-placeholder] outOfFlowFrame=Block(span)(-1)@7ff0c1f6d250
Placeholder(span)(-1)@7ff0c1f6d1d8 parent=7ff0c119b3c8 {0,0,0,0} [state=0001000000200402] [content=7ff0c11b6e50] [cs=7ff0c11fa2f8:-moz-oof-placeholder] outOfFlowFrame=Block(span)(-1)@7ff0c119abe8
>
>
>
>
>
>
AbsoluteList 7ff0bfb879a0 <
Block(span)(-1)@7ff0c119abe8 parent=7ff0c119a0b8 next=7ff0c1f6d250 {0,0,0,0} [state=0000002000d00702] [content=7ff0c11b6e50] [cs=7ff0c11fa208]<
>
Block(span)(-1)@7ff0c1f6d250 parent=7ff0c119a0b8 next=7ff0c1f6d380 {0,0,0,0} [state=0000002000d00702] [content=7ff0c11c7040] [cs=7ff0c11d76b8]<
>
Block(span)(-1)@7ff0c1f6d380 parent=7ff0c119a0b8 next=7ff0c1f6d4b0 {0,0,0,0} [state=0000002000d00702] [content=7ff0c11c74c0] [cs=7ff0c11d77a8]<
>
Block(span)(-1)@7ff0c1f6d4b0 parent=7ff0c119a0b8 next=7ff0c1f6d5e0 {0,0,0,0} [state=0000002000d00702] [content=7ff0c11c7670] [cs=7ff0c11d7988]<
>
Block(span)(-1)@7ff0c1f6d5e0 parent=7ff0c119a0b8 next=7ff0c1f6d710 {0,0,0,0} [state=0000002000d00702] [content=7ff0c11c7790] [cs=7ff0c11d8018]<
>
Block(span)(-1)@7ff0c1f6d710 parent=7ff0c119a0b8 next=7ff0c1f6d840 {0,0,0,0} [state=0000002000d00702] [content=7ff0c11c7820] [cs=7ff0c11d83d8]<
>
Block(span)(-1)@7ff0c1f6d840 parent=7ff0c119a0b8 next=7ff0c1f6d970 {0,0,0,0} [state=0000002000d00702] [content=7ff0c11c78b0] [cs=7ff0c11d8f18]<
>
Block(span)(-1)@7ff0c1f6d970 parent=7ff0c119a0b8 {0,0,0,0} [state=0000002000d00702] [content=7ff0c11c7a60] [cs=7ff0c11fa028]<
>
>
>
Comment 6•6 years ago
|
||
I am guessing the problematic abspos span
boxes are resizer handles from enableObjectResizing
in the testcase.
It seems we disabled those resizers for images and tables in bug 1449564. Seems like perhaps we should do it for video as well?
Updated•6 years ago
|
Comment 7•6 years ago
|
||
masayuki, do you know how/where these resizer <span>
elements get generated, and how best to prevent them from being added as a child of a <video> element? (Can/should we disable them entirely for this case, given that video element is a container frame that only expects a few specific children and no others?)
In the meantime, I think we can increase fuzzer quality-of-life (and reflect reality) by reducing the severity of this assertion -- I'll spin off a helper for that.
Updated•6 years ago
|
Comment 8•6 years ago
|
||
First of all, I should explain the background. Our editor may create anonymous children for some specific editing ability. There are 3 case:
- resizers to resize object like
<img>
. - buttons to add/remove table row/column to edit structure of
<table>
. - grabber to move absolute positioned element.
Currently, those UIs have not been implemented by modern browsers except Gecko. And those UIs are now hidden by default (bug 1449564).
However, for backward compatibility, there are prefs to show these UIs by default by users, and also there are commands forcibly to enable them by web apps. Therefore, these UIs are still alive in the web. (Actually these UIs are still used intentionally according to telemetry.) Additionally, these UIs are available by default on Thunderbird's email composer. So, making resizers for <video>
completely disabled might break some user experience.
So, personally, I'd like to recommend that such assertion should ignore frames which are created for native anonymous nodes like scrollbars.
- Resizers are created here: https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/editor/libeditor/HTMLEditorObjectResizer.cpp#54
- Buttons for
<table>
are created here: https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/editor/libeditor/HTMLInlineTableEditor.cpp#36 - Grabber is created here: https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/editor/libeditor/HTMLAbsPositionEditor.cpp#226
Updated•3 years ago
|
Description
•